home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1545.txt < prev    next >
Text File  |  1994-08-01  |  9KB  |  284 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      D. Piscitello
  8. Request for Comments: 1545                                      Bellcore
  9. Category: Experimental                                     November 1993
  10.  
  11.  
  12.             FTP Operation Over Big Address Records (FOOBAR)
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  This memo does not specify an Internet standard of any
  18.    kind.  Discussion and suggestions for improvement are requested.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This paper describes a convention for specifying longer addresses in
  24.    the PORT command.
  25.  
  26. Introduction
  27.  
  28.    This RFC specifies a method for assigning long addresses in the
  29.    HOST-PORT specification for the data port to be used in establishing
  30.    a data connection for File Transfer Protocol, FTP (STD 9, RFC 959).
  31.    This is a general solution, applicable for all "next generation" IP
  32.    alternatives, and can also be extended to allow FTP operation over
  33.    transport interfaces other than TCP.
  34.  
  35. Acknowledgments
  36.  
  37.    Many thanks to all the folks in the IETF who casually mentioned how
  38.    to do this, but who left it to me to write this RFC.  Special thanks
  39.    to Rich Colella, Bob Ullmann, Shawn Ostermann, Steve Lunt, and Brian
  40.    Carpenter who had the time and decency to comment on the initial
  41.    draft.  :-)
  42.  
  43. 1.  Background
  44.  
  45.    The PORT command of File Transfer Protocol allows users to specify an
  46.    address other than the default data port for the transport connection
  47.    over which data are transferred. The PORT command syntax is:
  48.  
  49.       PORT <SP> <host-port> <CRLF>
  50.  
  51.    The <host-port> argument is the concatenation of a 32-bit internet
  52.    <host-address> and a 16-bit TCP <port-address>.  This address
  53.    information is broken into 8-bit fields and the value of each field
  54.    is transmitted as a decimal number (in character string
  55.  
  56.  
  57.  
  58. Piscitello                                                      [Page 1]
  59.  
  60. RFC 1545                  FTP Over Big Address             November 1993
  61.  
  62.  
  63.    representation).  The fields are separated by commas.  A port command
  64.    is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where h1 is the
  65.    high order 8 bits of the internet host address.
  66.  
  67.    To accommodate larger network addresses anticipated for all IP "next
  68.    generation" alternatives, new commands and reply codes are needed for
  69.    FTP.  This memo addresses these needs.
  70.  
  71. 2.  The LPRT Command
  72.  
  73.    The LPRT command allows users to specify a "long" address for the
  74.    transport connection over which data are transferred. The LPRT
  75.    command syntax is:
  76.  
  77.       LPRT <SP> <long-host-port> <CRLF>
  78.  
  79.    The <long-host-port> argument is the concatenation of the following
  80.    fields;
  81.  
  82.    o  an 8-bit <address-family> argument (af)
  83.  
  84.    o  an 8-bit <host-address-length> argument (hal)
  85.  
  86.    o  a <host-address> of <host-address-length> (h1, h2, ...)
  87.  
  88.    o  an 8-bit <port-address-length> (pal)
  89.  
  90.    o  a <port-address> of <port-address-length> (p1, p2, ...)
  91.  
  92.    The <address-family> argument takes the value of the version number
  93.    of IP (see Assigned Numbers, STD 2, RFC 1340), or generally speaking,
  94.    an Internet layer protocol.  Relevant assigned IPng version numbers
  95.    are:
  96.  
  97.      Decimal         Keyword
  98.      ------          -------
  99.      0               reserved
  100.      1-3             unassigned
  101.      4               Internet Protocol (IP)
  102.      5               ST Datagram Mode
  103.      6               SIP
  104.      7               TP/IX
  105.      8               PIP
  106.      9               TUBA
  107.      10-14           unassigned
  108.      15              reserved
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Piscitello                                                      [Page 2]
  115.  
  116. RFC 1545                  FTP Over Big Address             November 1993
  117.  
  118.  
  119.    The value of each field is broken into 8-bit fields and the value of
  120.    each field is transmitted as an unsigned decimal number (in character
  121.    string representation, note that negative numbers are explicitly not
  122.    permitted).  The fields are separated by commas.
  123.  
  124.    A LPRT command is thus of the general form
  125.  
  126.       LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
  127.  
  128.    where h1 is the high order 8 bits of the internet host address, and
  129.    p1 is the high order 8 bits of the port number (transport address).
  130.  
  131. 3.  The LPSV Command
  132.  
  133.    The L(ONG) PASSIVE command requests the server-DTP to listen on a
  134.    data port other than its default data port and to wait for a
  135.    connection rather than initiate one upon receipt of a transfer
  136.    command.  The response to this command includes the address family,
  137.    host address length indicator, host address, port address length, and
  138.    port address this server is listening on.  The reply code and text
  139.    for entering the passive mode using a long address is 228
  140.    (Interpretation according to FTP is: positive completion reply 2yz,
  141.    connections x2z, passive mode entered using long address xy8).  The
  142.    suggested textual message to accompany this reply code is:
  143.  
  144.       228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,p1,p2...)
  145.  
  146. 4.  Permanent Negative Completion Reply Codes
  147.  
  148.    The negative completion reply codes that are associated with syntax
  149.    errors in the PORT and PASV commands are appropriate for the LPRT and
  150.    LPSV commands (500, 501).  An additional negative completion reply
  151.    code is needed to distinguish the case where a host supports the LPRT
  152.    or LPSV command, but does not support the address family specified.
  153.    Of the FTP function groupings currently defined for reply codes
  154.    (syntax, information, connections, authentication and accounting, and
  155.    file system), "connections" seems the most logical choice; thus, an
  156.    additional negative command completion reply code, 521 is added, with
  157.    the following suggested textual message:
  158.  
  159.       521 Supported address families are (af1, af2, ..., afn)
  160.  
  161.    Where (af1, af2, ..., afn) are the values of the version numbers of
  162.    the "next generation" or other protocol families supported.  IP
  163.    address noted earlier.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Piscitello                                                      [Page 3]
  171.  
  172. RFC 1545                  FTP Over Big Address             November 1993
  173.  
  174.  
  175. 5.  Rationale
  176.  
  177.    An explicit address family argument in the LPRT command and LPSV
  178.    reply allows the Internet community to experiment with a variety of
  179.    "next generation IP" alternatives within a common FTP implementation
  180.    framework.  (It also allows the use of a different address family on
  181.    the command and data connections.)  An explicit length indicator for
  182.    the host address is necessary because some of the IPNG alternatives
  183.    make use of variable length addresses.  An explicit host address is
  184.    necessary because FTP says it's necessary.
  185.  
  186.    The decision to provide a length indicator for the port number is not
  187.    as obvious, and certainly goes beyond the necessary condition of
  188.    having to support TCP port numbers. Currently, at least one IPng
  189.    alternative (TP/IX) supports longer port addresses.  And given the
  190.    increasingly "multi-protocol" nature of the Internet, it seems
  191.    reasonable that someone, somewhere, might wish to operate FTP operate
  192.    over Appletalk, IPX, and OSI networks as well as TCP/IP networks.
  193.    (In theory, FTP should operate over *any* transport protocol that
  194.    offers the same service as TCP.) Since some of these transport
  195.    protocols may offer transport selectors or port numbers that exceed
  196.    16 bits, a length indicator may be desirable.  If FTP must indeed be
  197.    changed to accommodate larger network addresses, it may be prudent to
  198.    determine at this time whether the same flexibility is useful or
  199.    necessary with respect to transport addresses.
  200.  
  201. 6.  Conclusions
  202.  
  203.    The mechanism defined here is simple, extensible, and meets both IPNG
  204.    and possibly multi-protocol internet needs.
  205.  
  206. 7.  References
  207.  
  208.    STD 9, RFC 959  Postel, J., and J. Reynolds, "File Transfer Protocol",
  209.                    STD 9, RFC 959, USC/Information Sciences Institute,
  210.                    October 1985.
  211.  
  212.    STD 2, RFC 1340 Reynolds, J., and J. Postel, "Assigned Numbers",
  213.                    STD 2, RFC 1340, USC/Information Sciences Institute,
  214.                    July 1992.  (Does not include recently assigned IPv7
  215.                    numbers).
  216.  
  217.    STD 3, RFC 1123 Braden, R., Editor, "Requirements for Internet
  218.                    Hosts - Application and Support", STD 3, RFC 1123,
  219.                    USC/Information Sciences Institute, October 1989.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Piscitello                                                      [Page 4]
  227.  
  228. RFC 1545                  FTP Over Big Address             November 1993
  229.  
  230.  
  231. 8.  Security Considerations
  232.  
  233.    Security issues are not discussed in this memo.
  234.  
  235. 9.  Author's Address
  236.  
  237.    David M. Piscitello
  238.    Bell Communications Research
  239.    NVC 1C322
  240.    331 Newman Springs Road
  241.    Red Bank, NJ 07701
  242.  
  243.    EMail: dave@mail.bellcore.com
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Piscitello                                                      [Page 5]
  283.  
  284.